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Abstract.  Wireless  networks  are  an  ideal  environment  for  mobile  agents,  since  their  mobility  allows  them  to  move  across  an  unreliable 
link  to  reside  on  a  wired  host,  next  to  or  closer  to  the  resources  that  they  need  to  use.  Furthermore,  client-specihc  data  transformations 
can  be  moved  across  the  wireless  link  and  run  on  a  wired  gateway  server,  reducing  bandwidth  demands.  In  this  paper  we  examine  the 
tradeoffs  faced  when  deciding  whether  to  use  mobile  agents  in  a  data-hltering  application  where  numerous  wireless  clients  filter  information 
from  a  large  data  stream  arriving  across  the  wired  network.  We  develop  an  analytical  model  and  use  parameters  from  filtering  experiments 
conducted  during  a  US  Navy  Fleet  Battle  Experiment  to  explore  the  model’s  implications. 
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1.  Introduction 

Mobile  agents  are  programs  that  can  migrate  from  host  to  host 
in  a  network  of  computers,  at  times  and  to  places  of  their  own 
choosing.  Unlike  applets,  both  the  code  and  the  execution 
state  (heap  and  stack)  move  with  the  agent;  unlike  processes 
in  process-migration  systems,  mobile  agents  move  when  and 
where  they  choose.  They  are  typically  written  in  a  language 
that  can  be  interpreted,  such  as  Java,  Tel,  or  Scheme,  and  thus, 
tend  to  be  independent  of  the  operating  system  and  hardware 
architecture.  Agent  programmers  typically  structure  their  ap¬ 
plication  so  that  the  agents  migrate  to  the  host(s)  where  they 
can  find  the  desired  service,  data,  or  resource,  so  that  all  inter¬ 
actions  occur  on  the  local  host,  rather  than  across  the  network. 
In  some  applications,  a  single  mobile  agent  migrates  sequen¬ 
tially  from  host  to  host;  in  others,  an  agent  spawns  one  or 
more  child  agents  to  migrate  independently. 

A  mobile-agent  programmer,  thus,  has  an  option  not  avail¬ 
able  to  the  programmer  of  a  traditional  distributed  applica¬ 
tion:  to  move  the  code  to  the  data,  rather  than  moving  the 
data  to  the  code.  In  many  situations,  moving  the  code  may 
be  faster,  if  the  agent’s  state  is  smaller  than  the  data  that 
would  be  moved.  Or,  it  may  be  more  reliable,  since  the  ap¬ 
plication  is  only  vulnerable  to  network  disconnection  dur¬ 

*  An  earlier  version  of  this  work  appeared  in  the  Proceedings  of  the  Work¬ 
shop  on  Modeling,  Analysis  and  Simulation  of  Wireless  and  Mobile  Sys¬ 
tems  (MSWiM  2000).  This  research  was  supported  by  the  DARPA  CoABS 
Program  (DARPA  contracts  F30602-9B-2-0107  and  F30602-98-C-0162 
for  Dartmouth  and  Lockheed  Martin,  respectively)  and  by  the  DoD  MURI 
program  (AFoSR  contract  F49620-97-1-03821  for  both  Dartmouth  and 
Lockheed  Martin). 
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ing  the  agent  transfer,  not  during  the  interaction  with  the 
resource.  For  a  survey  of  the  potential  of  mobile  agents, 
see  [3,5]. 

These  characteristics  make  mobile-agent  technology  espe¬ 
cially  appealing  in  wireless  networks,  which  tend  to  have  low 
bandwidth  and  low  reliability.  A  user  of  a  mobile  comput¬ 
ing  device  can  launch  a  mobile  agent,  which  jumps  across 
the  wireless  connection  into  the  wired  Internet.  Once  there,  it 
can  safely  roam  among  the  sites  that  host  mobile  agents,  in¬ 
teracting  either  with  local  resources  or,  when  necessary,  with 
resources  on  remote  sites  that  are  not  willing  to  host  mobile 
agents.  Once  it  has  completed  its  task,  it  can  return  to  (or  send 
a  message  to)  its  user,  using  the  wireless  network. 

Clearly,  the  agent  case  avoids  the  transmission  of  unnec¬ 
essary  data,  but  does  require  the  transmission  of  agent  code 
from  client  to  server.  The  total  bandwidth  consumed  for  code 
transmission  depends  on  the  agent  size  and  arrival  rate.  For 
most  reasonable  agent  code  sizes  and  arrival  rates,  the  sav¬ 
ings  in  data  transmission  may  be  much  larger  than  the  code 
transmissions.  Of  course,  each  client’s  code  could  be  prein¬ 
stalled  on  the  server.1  This  approach  presupposes,  however, 
that  the  clients  are  known  in  advance.  In  many  of  the  environ¬ 
ments  that  we  consider,  new  clients  with  new  code  can  appear 
at  any  time,  and  possibly  disappear  only  a  short  while  later. 
In  scenarios  like  the  one  discussed  in  this  paper,  we  need  at 
least  a  dynamic-installation  facility,  and  mobile  agents  give 
us  the  flexibility  to  move  filtering  code  to  any  point  in  the  net- 

1  In  fact,  most  mobile-agent  systems  include,  or  plan  to  include,  some  kind 
of  code-caching  functionality,  so  that  the  agent  code  is  transferred  only 
the  first  time  that  an  agent  visits  a  machine. 
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work,  and  to  move  the  code  again  as  the  situation  changes. 
Although  we  do  not  consider  such  multi-machine  scenarios 
in  this  initial  paper,  they  will  be  an  important  part  of  future 
work. 

In  this  paper  we  analyze  the  potential  performance  bene¬ 
fits  of  mobile  agents  in  a  typical  data-filtering  scenario.  The 
scenario  is  based  on  a  filtering  experiment  that  was  conducted 
during  a  US  Navy  Fleet  Battle  Experiment  (FBE).  In  the  FBE 
experiment,  mobile  agents  were  sent  across  a  wireless  link 
from  the  USS  Coronado  to  a  shore-based  intelligence  data¬ 
base,  where  they  filtered  incoming  intelligence  reports  to  find 
and  return  only  those  reports  relevant  to  the  Coronado’s  cur¬ 
rent  mission.  Although  the  scenario  is  drawn  from  an  actual 
military  exercise,  it  is  sufficiently  general  to  reflect  many  ap¬ 
plications,  from  military  applications  in  which  soldiers  mon¬ 
itor  weather,  terrain  and  troop  movements,  to  commercial  ap¬ 
plications  in  which  consumers  monitor  stock  reports  and  news 
stories. 

In  our  scenario  there  are  numerous  information  produc¬ 
ers,  each  of  which  pushes  out  a  steady  stream  of  informa¬ 
tion,  such  as  weather  observations,  stock  quotes,  news  sto¬ 
ries,  traffic  reports,  plane  schedules,  troop  movements,  and 
the  like.  Clearly  each  source  has  a  different  data  rate  and 
frequency.  There  are  also  numerous  information  consumers, 
whose  computers  are  connected  to  a  wireless  network  chan¬ 
nel.  We  assume  that  the  information  streams  gather  at  a  gate¬ 
way  server,  which  then  transmits  the  data  across  the  wireless 
channel  to  the  consumers.  Although  we  model  a  single  server 
machine,  in  a  large  system  we  expect  that  the  server  would 
be  a  multiprocessor  or  cluster,  such  as  those  used  in  large  In¬ 
ternet  servers  today.  Although  we  model  a  single  wireless 
channel,  the  results  are  easily  extensible  to  multiple  channels, 
each  with  its  own  server,  whether  in  separate  or  overlapping 
regions. 

The  overall  picture  is  shown  in  figure  1 . 

Each  consumer  is  interested  in  a  different  (but  not  neces¬ 
sarily  disjoint)  subset  of  the  data.  In  particular,  each  consumer 
is  interested  in  only  a  few  information  streams,  and  then  only 
in  some  filtered  set  of  items  in  those  streams.  For  example,  a 
traveler  might  monitor  the  weather  stream,  but  not  the  stock 
stream,  and  of  the  weather  stream,  might  care  only  about  the 
weather  in  those  locations  that  she  will  visit  today.  The  first 
step  requires  no  computation;  the  second  may  require  some 
computation  related  to  the  size  of  the  data  stream.  We  model 
a  consumer’s  interests  as  a  set  of  tasks,  all  running  on  that 
consumer’s  single  computer  client. 

We  compare  two  approaches  to  solving  this  problem: 

1 .  The  server  combines  and  broadcasts  all  the  data  streams 
over  the  wireless  channel.  Each  client  receives  all  of  the 
data,  and  each  task  on  each  client  machine  filters  through 
the  appropriate  streams  to  obtain  the  desired  data. 

2.  Each  task  on  each  client  machine  sends  one  mobile  agent 
to  the  server.  These  “proxy”  agents  filter  the  data  streams 
on  the  server,  sending  only  the  relevant  data  as  a  message 
to  the  corresponding  task  on  the  client. 


Information  sources 

Wireless  channel  F 

rid 

Clients 

Figure  1 .  The  scenario  we  analyze. 

We  use  two  performance  metrics  to  compare  these  two 
techniques:  the  bandwidth  required  and  the  computation  re¬ 
quired.  We  can  directly  compare  the  usage  of  the  two  tech¬ 
niques,  and  we  can  evaluate  the  capacity  needed  in  the  server 
or  the  network.  Clearly,  the  mobile  agent  approach  trades 
server  computation  (and  cost)  for  savings  in  network  band¬ 
width  and  client  computation,  a  valuable  tradeoff  if  band¬ 
width  is  limited  or  if  it  is  important  to  keep  client  weight  and 
power  requirements  (and  cost)  low. 

In  the  next  section,  we  present  the  FBE  experiment  in  more 
detail.  Then,  in  two  subsequent  sections,  we  define  the  para¬ 
meters  that  arise  during  the  analysis,  derive  the  basic  equa¬ 
tions,  and  interpret  their  significance.  In  section  4,  we  review 
the  parameter  values  that  we  were  able  to  obtain  from  the  ac¬ 
tual  FBE  experiment,  and  describe  the  experiments  that  we 
performed  to  obtain  values  for  other  key  parameters.  In  sec¬ 
tion  5,  we  use  these  values  to  explore  the  performance  space 
given  by  our  model.  We  describe  some  related  work  in  sec¬ 
tion  6  and  summarize  in  section  7. 


2.  The  Fleet  Battle  Experiment 

In  practice,  the  United  States  Navy  (USN)  Fleet  Battle  Exper¬ 
iment  (FBE)  series  involves  information-flow  architectures 
that  exemplify  the  general  scenario  described  in  the  introduc¬ 
tion.  In  FBE-Echo,  the  fifth  in  the  series,  Lockheed  Martin 
Advanced  Technology  Laboratories  (LM  ATL)  fielded  CAST, 
a  mobile-agent  application  that  optimized  the  flow  of  critical 
information  through  bandwidth-limited,  congested,  and  un¬ 
reliable  wireless  networks  [2],  As  the  results  later  in  this 
paper  indicate,  the  mobile-agent  solution  lowers  bandwidth 
consumption  in  the  limited  experiment  scenario  and  promises 
to  be  even  more  beneficial  in  a  realistic,  high-intensity  opera¬ 
tion. 

The  USN  Maritime  Battle  Center  in  Newport,  Rhode  Is¬ 
land,  conducts  semi-annual  FBEs  in  cooperation  with  the 
numbered  USN  fleets  with  the  goal  of  streamlining  and  in¬ 
vigorating  the  Navy’s  warfare  concept  development,  doctrine 
refinement  and  warfare  innovation  process.  FBE-Echo  was 
held  in  March  1999  in  the  San  Francisco  Bay  area,  and 
examined  operational  and  tactical  requirements  for  warfare 
in  the  years  2005-2010.  More  than  15  ships  and  12,000 
sailors  and  Marines  from  southern  California  participated. 
The  FBE-Echo  hypothesis  was  that  “warfighting  processes 
supported  by  new  concepts  and  technology  allow  the  Navy  to 
enter  and  remain  in  the  [coastal  region]  indefinitely  with  the 
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ability  to  provide  protection,  weapons  fires  and  C4I2  support 
to  forces  ashore.”3 

At  FBE-Echo,  CAST  was  integrated  into  the  Full  Dimen¬ 
sion  Protection  Cell  aboard  the  command  ship,  the  USS  Coro¬ 
nado.  CAST  spawned  a  set  of  mobile  “scout”  agents  to  corre¬ 
late  events  indicative  of  impending  Theater  Ballistic  Missile 
(TBM)  launches  and  send  filtered  reports  back  to  the  USS 
Coronado.  CAST  then  supplied  alerts  on  TBM  activity  to  the 
Air  Operations  Commander,  who  tasked  fleet  surveillance  as¬ 
sets  and  launched  a  simulated  preemptive  strike.  The  scout 
agents  traveled  across  the  SIPRNET,  the  secure  military  In¬ 
ternet,  from  the  USS  Coronado  to  a  simulated  shore-based 
intelligence  feed.  The  SIPRNET  link  between  the  USS  Coro¬ 
nado  and  the  shore  was  a  wireless  Super  High  Frequency 
(SHF)  satellite  communications  link,  whose  bandwidth  was 
768  kbps.4  Intelligence  reports  were  approximately  150  bytes 
in  size  and  arrived  in  bursts  spaced  about  every  four  minutes, 
with  each  burst  containing  five  to  ten  reports  at  a  rate  of  one 
report  every  four  seconds.  The  CAST  scout  agents  were  about 
1  KByte  in  size. 

The  main  benefit  of  CAST  was  that  agents  selectively 
scanned  and  filtered  the  incoming  intelligence  reports,  for¬ 
warding  only  those  that  correlated  to  a  significant  event.  The 
mobile  scout  agents  carried  selection  specifications  from  the 
USS  Coronado  across  the  wireless  link  to  the  remote  infor¬ 
mation  sources,  stayed  there  to  monitor  new  information,  and 
periodically  sent  back  a  much  reduced  set  of  data,  saving 
both  bandwidth  and  operator  attention  to  irrelevant  data.  Each 
TBM  event  differs  by  the  location,  the  initiating  event,  the  sets 
of  reports,  and  the  timelines,  so  that  an  implementation  with¬ 
out  mobile  filtering  logic  embodied  in  a  mobile  scout  agent 
would  have  been  cumbersome  and  complex. 

Another  benefit  of  CAST’s  mobile-agent  approach  was  its 
ability  to  handle  network  outages.  The  satellite  connection 
disconnected  frequently,  for  a  few  seconds  to  an  hour  at  a 
time.  With  a  mobile-agent  approach,  the  task  of  monitoring 
the  database  was  uninterrupted  once  agents  were  resident  on 
shore,  although,  of  course,  reports  that  passed  the  agents’  fil¬ 
ters  had  to  be  buffered  until  the  link  came  back  up.  New 
agents  were  programmed  to  repeatedly  attempt  the  ship-to- 
shore  leap  as  long  as  the  satellite  connection  was  down. 

In  the  exercise,  the  ratio  of  relevant  to  irrelevant  reports 
was  only  about  0.5,  since  the  simulated  intelligence  feed  did 
not  create  a  realistic  number  of  extraneous  “noise”  events,  and 
a  scout  agent  was  spawned  approximately  every  4  minutes.  In 
an  actual  high-intensity  operation,  the  number  of  extraneous 
reports  will  be  much  higher  and  drive  the  ratio  of  relevant 
to  irrelevant  reports  down  to  at  least  0.005.  Especially  in  an 
urban  scenario,  a  large  number  of  reports  would  be  generated 

2  C4I  is  a  military  abbreviation  for  Command,  Control,  Communications, 
Computers  and  Intelligence. 

3  Fleet  Battle  Experiment  Echo,  Asymmetric  Urban  Threat,  http: 
/ /www. nwdc  . navY.mil/navigation/mbc  . htm,  last  modified 
8/31/00,  last  accessed  9/17/00. 

4  In  this  paper,  we  use  K  and  M  to  mean  powers  of  two  (10  and  20,  respec¬ 
tively)  and  k  and  m  to  mean  powers  of  10  (3  and  6,  respectively).  Thus 
kbps  means  103  bits  per  second. 


by  MTI  (Moving  Target  Indicator)  and  ELINT  (Electronic  In¬ 
telligence)  sources.  The  JSTARS  MTI  sensor,  for  example, 
is  capable  of  reporting  on  100  targets  every  second.  A  real 
conflict  would  involve  several  JSTARS  and  other  sensor  plat¬ 
forms.  In  such  a  situation,  CAST  would  launch  a  larger  num¬ 
ber  of  scouts,  up  to  a  rate  of  10  per  second.  The  remaining 
parameters  are  identical  for  exercise  and  actual  scenarios. 

LM  ATL  has  tailored  the  CAST  mobile  agents  to  several 
other  military  applications,  including  the  DARPA  Small  Unit 
Operations  program  and  US  Army  intelligence  operations  [8], 
In  each  case,  mobile  agents  proved  to  be  effective  in  mitigat¬ 
ing  the  effects  of  bandwidth-limited,  unreliable,  wireless  net¬ 
works. 

To  fully  explore  the  general  scenario  presented  by  the 
FBE-Echo  CAST  experiments,  we  developed  an  analytic 
model.  The  model  considers  a  more  general  scenario  involv¬ 
ing  multiple  clients  (whereas  CAST  had  one,  the  USS  Coron¬ 
ado)  and  multiple  independent  streams  of  reports.  In  the  rest 
of  this  paper  we  present  our  model  and  sample  some  of  the 
performance  space  using  specific  parameters. 


3.  The  model 


Since  the  data  is  arriving  constantly,  we  think  of  the  system 
as  a  pipeline;  see  figure  2.  We  imagine  that,  during  a  time 
interval  t,  one  chunk  of  data  is  accumulating  in  the  incom¬ 
ing  network  buffers,  another  chunk  is  being  processed  on  the 
server,  another  chunk  is  being  transmitted  across  the  wireless 
network,  and  another  chunk  is  being  processed  by  the  clients. 
If  the  data  arrives  at  an  average  rate  of  d  bits  per  second,  the 
average  chunk  size  is  td  bits. 

For  the  pipeline  to  be  stable,  then,  each  stage  must  be  able 
to  complete  its  processing  of  data  chunks  in  less  than  t  time, 
on  average  (figure  3).  That  is,  T\  C  t,  7s  ^  /,  /\v  ^  t, 
and  7c  C  t.  In  the  analysis  that  follows  we  work  with  these 
steady-state  assumptions;  as  future  work,  we  would  like  to 
explore  the  use  of  a  queueing  model  to  better  understand  the 
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Figure  2.  The  scenario  viewed  as  a  pipeline. 
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Figure  3.  The  pipeline  timing  diagram.  The  letters  represent  data  chunks.  For 
example,  between  time  3 1  and  4 1  chunk  A  is  being  processed  by  the  clients, 
chunk  B  is  being  transmitted  from  the  server  to  the  clients,  chunk  C  is  being 
processed  by  the  server,  and  chunk  D  is  being  received  by  the  server. 
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dynamic  properties  of  this  system,  such  as  the  buffer  require¬ 
ments  (queue  lengths). 

3.1.  The  parameters 

Below  we  define  all  of  the  parameters  used  in  our  model,  for 
easy  reference: 

•  d  —  input  data  streams’  speed  (bits/s); 

•  t  —  time  interval  (s); 

•  D  —  td,  the  size  of  a  data  chunk  arriving  during  time 
period  t  (bits); 

•  B  =  wireless  channel’s  total  physical  bandwidth  (bits/s); 

•  fa  —  communication  overhead  factor  for  broadcast 

(A  <  i); 

•  Z?b  =  Bfl b,  the  effective  bandwidth  available  for  broadcast 
(bits/s); 

•  pa  —  communication  overhead  factor  for  agents  (fia  <  1); 

•  Bd  —  Bfld.  the  effective  bandwidth  available  for  agent 
messages  (bits/s); 

•  B\  —  the  bandwidth  available  in  the  server’s  wired  Inter¬ 
net  connection,  for  receiving  data  streams  (bits/s);  pre¬ 
sumably  B\^>  B; 

•  n  —  number  of  client  machines; 

•  i  —  index  of  a  client  machine  (1  ^  i  ^  n); 

•  m  j  =  number  of  tasks  on  each  client  machine  ;, 

1  ^  i  ^  n; 

•  j  —  index  of  a  task  (1  ^  j  A  m, ); 

•  m  —  ^  mi,  total  number  of  tasks; 

•  r  =  arrival  rate  of  new  agents  uploaded  from  the  clients  to 
the  server  (per  second); 

•  K  —  average  agent  size  (bits); 

•  F--  —  the  fraction  of  the  total  data  D  that  task  j  on  client  i 

'J 

chooses  to  process  (by  choosing  to  process  only  certain 
data  streams); 

•  Fjj  =  the  fraction  of  the  data  processed  by  task  j  on 
client  i ,  produced  as  output; 

•  CijiD.Ftj.Fij)  computational  complexity  of  task  j  on 
client  i  (operations);5 

•  p,  —  the  average  computational  complexity,  for  a  given  D 
(pi  —  (1  /m)J2ijCij(D,  Fjj,  Fjj))-,  it  is  a  convenient 
shorthand; 

•  Cinit  =  average  number  of  operations  needed  for  a  new 
agent  to  start  and  to  exit; 

•  Sf  —  performance  of  client  machine  i  (operations/s); 

•  a;c  =  performance  efficiency  of  the  software  platform  on 
the  client  machine  i  (a?  <  1); 

•  Ss  =  performance  of  the  server  machine  (operations/s);6 

5  We  expect  that  c( )  will  have  little  dependence  on  D.  directly,  but  more  on 
DF'ij- 

6  We  assume  that  all  agents  get  equal-priority  access  to  server  cycles. 


•  as  =  performance  efficiency  of  the  software  platform  on 
the  server  (as  <  1). 

Notes.  B  is  the  raw  bandwidth  of  the  wireless  channel,  but 
that  bandwidth  is  never  fully  available  to  application  commu¬ 
nication.  We  assume  that  a  broadcast  protocol  would  actually 
achieve  bandwidth  B\,  and  a  mobile-agent  messaging  proto¬ 
col  would  achieve  bandwidth  Bd  after  including  the  overhead 
of  protocol  and  retransmissions.  In  section  4  we  discuss  our 
measurements  of  Bd  and  IF- 

When  comparing  a  mobile-agent  approach  to  a  more  tra¬ 
ditional  approach,  it  is  most  fair  to  expect  that  a  traditional 
system  would  use  compiled  code  on  the  client  (such  as  com¬ 
piled  C  code),  whereas  a  mobile-agent  system  would  use  in¬ 
terpreted  code  on  the  server  (because  most  mobile-agent  sys¬ 
tems  only  support  interpreted  languages  like  Java  or  Tel).  The 
client  and  server  will  likely  be  different  hardware  and  have 
different  speeds,  Sc  and  Ss,  respectively.  Because  the  lan¬ 
guage,  compiler,  and  run-time  system  impose  overhead,  the 
client  runs  at  a  fraction  ac  of  the  full  speed  Sc,  and  the  server 
runs  at  a  fraction  as  of  the  full  speed  Ss.  Of  course,  a  <  1, 
and  we  expect  cvs  <  «c,  since  filtering  agents  on  the  server 
will  be  interpreted,  whereas  filtering  code  on  the  clients  will 
be  compiled.  On  the  other  hand,  we  expect  Ss  Sc. 

Computed  values.  As  hinted  in  the  figures  above,  the  fol¬ 
lowing  values  are  computed  as  a  result  of  the  other  parame¬ 
ters: 

•  7):  the  time  for  transmission  across  the  Internet  to  the 
server; 

•  7s:  the  time  for  processing  on  the  server; 

•  7w:  the  time  for  transmission  across  the  wireless  network; 

•  7'c :  the  time  for  processing  on  the  client. 

Most  of  these  have  two  variants,  i.e.,  ?sa,  7wa  and  7ca 
for  the  agent  case,  and  7sb,  7\vb  and  Tcb  for  the  broadcast 
case. 

3.2.  Computing  the  constraints 

As  mentioned  above,  each  stage  of  the  pipeline  must  complete 
in  less  than  time  t,  that  is,  T\  F  t,  C-  t,  7w  ^  t,  and 
7’c  <  t  . 

Internet,  T\.  Since  we  are  concerned  with  alternatives  for 
the  portion  of  the  system  spanning  the  wireless  network,  we 
do  not  specifically  model  the  Internet  portion.  We  assume  that 
the  Internet  is  not  the  bottleneck,  that  is,  it  is  sufficiently  fast 


to  deliver  all  data  streams  on  schedule: 

D 

II 

/A 

(1) 

B  i 

d  F  B[. 

(2) 

of  course. 
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Server,  T$.  In  the  broadcast  case,  the  server  simply  merges 
the  data  streams  arriving  from  the  Internet.  This  step  is  trivial, 
and  in  any  case  7sb  <  t  almost  certainly. 

In  the  agent  case,  data  filtering  happens  on  the  server.  The 
server’s  time  is  a  combination  of  the  filtering  costs  plus  the 
time  spent  initializing  newly  arrived  agents: 


activity  adds  rK  bits  per  second  (rtK  bits  per  chunk)  to  the 
total  traffic.  So,  updating  equation  (11)  we  have 


mDF'F  +  rtK 


t. 


(12) 


which  leads  to  a  bound  on  the  number  of  agents  (tasks): 


**  =  ££ 

i=l  7=1 


djiD,  F[j ,  Fjj )  rtQ 


a*Ss 


asSs 


(3) 


If  we  know  that  the  expected  value  of  the  computing  com¬ 
plexity  Cjj  is  ji,  then  we  can  simplify  and  obtain  a  bound  on 
the  number  of  client  tasks  (agents),  m.  That  is,  we  assume 
that 


m  ^ 


fia  -  rK 
dF'F 


(13) 


When  does  the  mobile-agent  approach  require  less  wire¬ 
less  bandwidth?  We  can  compute  the  bandwidth  needed 
from  the  amount  of  data  transmitted  for  one  chunk,  expanded 
by  1//3  to  account  for  the  protocol  overhead,  then  divide  by 
the  time  t  for  one  chunk: 


X.ijCijd),  FljJ-ij) 

mf! 

(4) 

asSs 

asSs ' 

Now  7sa  ^  t, 

mu  +  rtCinit  ^ 
asSs  ^  ’ 

(5) 

m  <  (asSs  -  rCinit) 

t 

(6) 

Wireless  network,  T\v.  The  broadcast  case  is  relatively  sim¬ 
ple,  since  all  of  the  chunk  data  D  is  sent  over  the  channel: 

Twb  =  —  <  t,  (7) 

Ob 

d  <  fib-  (8) 


Recall  that  B\,  =  Bfih,  and  that  D  —  td. 

In  the  agent  case,  agents  filter  out  most  of  the  data  and 
send  a  subset  of  the  data  items  across  the  wireless  network,  as 
messages  back  to  their  task  on  the  client.  Agent,;'  sends,  on 
average,  DFB  F,  j  bits  from  a  chunk.  The  total  time  to  transfer 
all  agents’  messages  is,  thus. 


B, 


(9) 


If  we  consider  the  average  agent  and  define 

F'F^-TFljFij,  (10) 

hj 


then,  since  there  are  m  agents, 
mDF'  F 


(11) 


It  is  not  quite  that  simple,  however. 

The  wireless  channel  also  carries  agents  from  the  clients 
to  the  server,  so  we  must  adjust  for  the  bandwidth  occupied 
by  traffic  in  the  reverse  direction.7  Recall  that  new  agents 
of  size  K  jump  to  the  server  at  a  rate  r  per  second.  This 


Note  that  inequality  (16)  is  nearly  the  same  as  inequality  (13). 
If  broadcast  is  possible  ( d  ^  /([-,),  then  we  should  use  broad¬ 
cast  iff  m  exceeds  the  limit  provided  in  inequality  (16).  If 
broadcast  is  impossible  ( d  >  /([,  ),  then  of  course  the  mobile- 
agent  approach  is  the  only  choice,  but  the  number  of  agents 
must  be  kept  within  the  limit  specified  in  (13). 

Note  that  in  the  broadcast  case  the  wireless  bandwidth 
must  scale  with  the  input  stream  rate,  while  in  the  agent  case 
the  wireless  bandwidth  must  scale  with  the  number  of  agents 
and  the  relevance  of  the  data.  Since  we  expect  that  most  of 
the  data  will  be  filtered  out  by  agents  (i.e.  ,  F'F  <  0.01),  the 
agent  approach  should  scale  well  to  systems  with  large  data¬ 
flow  rates  and  moderate  client  populations. 


Client,  Tq.  We  consider  only  the  processing  needed  to  filter 
the  data  stream,  and  assume  that  the  clients  have  additional 
power  and  time  needed  for  an  application- specific  consump¬ 
tion  of  the  data.  Also,  we  assume  the  client  has  sufficient 
processing  power  to  launch  agents  at  rate  r/n. 

In  the  broadcast  case,  the  data  filtering  happens  on  the 
clients.  We  must  design  for  the  slowest  client,  i.e., 


m; 

7cb  =  max  £ 

i  z — ' 

j= 1 


dj(D,  F!  Fij) 

— tfsF - • 


(17) 


If  all  n  client  hosts  were  the  same,  we  could  write  simply 


7cb  = 


m  fi 


n  ac  Sc  ’ 


(18) 


and  since  7cb  ^  t  is  required. 


m  ^  nac  Sc 


t 


(19) 


7  Unless  the  channel  is  full  duplex,  in  which  case  there  is  no  impact  on  the  lit  the  agent  case  there  is  no  data  filtering  on  the  clients,  SO 
downlink  bandwidth.  Here  we  assume  a  half-duplex  channel.  Tq\  —  0. 
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Table  1 

Summary  of  the  constraints  derived  earlier,  along  with  simplified  constraints  that  assume  r  —  0.  T\  and  Tq  are  not  affected  by  r.  At 
the  bottom,  we  show  the  comparison  where  agents  require  less  wireless  bandwidth  than  the  broadcast  approach. 


Stage 

Limits 

Simplified  limits 

Broadcast 

Agent 

Broadcast 

Agent 

Internet,  T\ 

Server,  T§ 

Wireless,  7\v 

Client,  Tq 

d  <  B\ 

negligible 

d  <  Bb 

m  ^  n(acSc)  — 

n 

d^Bi 

m  y  ( asSs  -  rCinit)  ~ 
n 

„  B*~rK 

d  ^  Bi 

negligible 

d  Bb 

m  ^  «(o,cSc)  — 

n 

d  ^  Bi 

m  <  (o^S5)  - 

n 

<  Ba 

m  ^  dF'F 
negligible 

m  ^  dF'F 
negligible 

Comparison 

Simplified  comparison 

i  , 

<  Ba  rK  \ 

1 

Ba 

Wireless,  7\y 

m  < 

m  <  — — 

F'F  ' 

\Bb  d  ) 

F'F  Bb 

3.3.  Commentary 


The  results  are  summarized  in  table  1 . 

We  can  see  that  the  agent  approach  fits  within  the  con¬ 
straints  of  the  wireless  network  if  the  number  (m  and  r)  and 
size  ( K )  of  agents  is  small,  or  the  filtering  ratios  ( F'F )  are 
low. 

We  believe  that,  in  many  realistic  applications,  most  agents 
will  remain  on  the  server  for  a  long  time,  and  new  agents  will 
be  installed  rarely.  Thus,  r  is  small.  Most  of  the  time,  r  —  0. 
This  assumption  simplifies  some  of  the  equations  into  a  more 
readable  form,  as  shown  in  the  right  side  of  the  table. 

Notice  that  the  broadcast  case  scales  infinitely  with  the 
number  of  clients,  but  to  add  tasks  to  a  client  or  to  add  data  to 
the  input  stream  requires  the  client  processor  to  be  faster.  On 
every  client  i 


^ctjiD.F!  Fij) 

>  - - - <  t 

h  a's' 

(20) 

si  >  Y,  — — F — 

“  up 

7=1 

(21) 

so,  as  cl  or  t  increases  or  as  m ,  (the  range  of  j)  increases, 
S'?  must  increase. 

The  mobile-agent  case,  on  the  other  hand,  requires  little 
from  the  client  processor  (for  filtering),  but  requires  a  lot  more 
from  the  server  processor.  That  processor  must  scale  with  the 
input  data  rate,  the  number  of  clients,  and  the  number  of  tasks 
per  client: 


Ss  ^ 


mp.  +  rfCinit 
tas 


(22) 


On  the  other  hand,  it  may  be  easier  to  scale  a  server  in  a 
fixed  facility  than  to  increase  the  speed  of  individual  client 
machines,  especially  if  the  server  lives  in  a  comfortable  ma¬ 
chine  room  while  the  clients  are  mobile,  battery-operated  field 
machines. 


Buffers  in  the  pipeline.  Since  we  model  our  application  as 
a  pipeline,  we  are  primarily  concerned  with  throughput  and 
bandwidth,  rather  than  response  time  and  latency.  As  long  as 


the  pipeline  is  stable  in  the  steady  state,  i.e.,  no  component’s 
capacity  is  exceeded,  the  system  works.  All  of  our  above  cal¬ 
culations  are  based  on  that  approach. 

In  a  real  system,  of  course,  the  data  flow  fluctuates  over 
time.  Buffers  between  each  stage  of  the  pipeline  hold  data 
when  one  stage  produces  data  faster  than  the  next  stage  can 
process  it.  In  a  more  complete  analysis  we  would  use  a  full 
queuing  model  to  analyze  the  distribution  of  buffer  sizes  at 
each  stage  of  the  pipeline,  given  distributions  for  parame¬ 
ters  like  d,  r,  and  c().  We  leave  this  analysis  for  future 
work. 

Latency.  Although  we  are  most  concerned  with  through¬ 
put,  in  our  application  some  clients  may  also  be  concerned 
about  latency.  In  other  words,  it  would  be  a  shame  if  time- 
critical  data  were  delayed  from  reaching  the  client.  Which 
approach  leads  to  less  latency,  say,  from  the  time  it  reaches 
the  server  until  the  time  it  reaches  the  client  application?  Con¬ 
sider  the  flow  of  a  specific  data  item  through  the  pipeline:  it  is 
processed  on  the  server,  transmitted  on  the  wireless  network, 
and  processed  on  the  client.  It  must  share  each  of  these  re¬ 
sources  with  other  data  items  in  its  chunk,  and  it  must  share 
the  server  and  wireless  network  with  other  clients.  On  av¬ 
erage,  each  of  m  agents  may  require  only  T%\/ m  CPU  time 
on  the  shared  server.  If  the  server  divides  its  time  finely  and 
evenly,  all  tasks  will  complete  their  computation  at  time  T$,\. 
If  the  server  divides  its  time  coarsely,  the  average  task  com¬ 
pletes  in  half  that  time,  at  time  7sa/2.  A  similar  analysis  can 
be  made  for  the  wireless  network. 

Assuming  fine-grain  sharing  of  the  server  and  network,  the 
latencies  are 


La  —  Tsa  +  Twa  +  Tqa,  (23) 

Lb  —  Tsb  +  ?wb  +  Tqb  ■  (24) 


If  we  ignore  the  arrival  of  new  agents  (i.e,,  r  =  0),  and  assume 
that  all  clients  are  identical,  we  have 


mix  mDF'F 

La  —  H - - - h  0, 


asSs 


B a 
mp. 


D 

Lb  —  OH - . 

Z?b  nacSc 


(25) 

(26) 
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Unfortunately,  it  is  difficult  to  compare  these  two  without 
specific  parameter  values. 

We  wonder,  however,  about  the  value  of  such  a  latency 
analysis.  Given  a  specific  data  rate  d,  one  must  choose  a 
server  speed,  wireless  network  bandwidth,  and  client  speed, 
that  can  just  keep  up  with  the  data  flow.  That  is,  in  time  in¬ 
terval  f  two  of  those  three  components  must  each  be  able  to 
process  D  data.  Their  combined  latency  is  2 1.  With  suffi¬ 
ciently  small  t,  say,  1-10  s,  it  seems  likely  this  latency  would 
suffice  for  most  applications.  Although  one  approach  may 
have  a  little  less  latency  than  the  other,  the  data  flow  rate  re¬ 
mains  the  same.  One  could  reduce  latency  by  making  bal¬ 
anced  improvements  to  the  two  components  with  non-zero  la¬ 
tency;  this  improvement  may  be  easier  in  the  agent  approach, 
because  it  may  be  easier  to  upgrade  the  server  than  thousands 
of  clients. 


Server  cluster 


gateway 


Figure  4.  The  experimental  platform,  in  which  the  server  is  a  cluster  of  work¬ 
stations,  sending  its  data  through  a  wireless  gateway  machine  to  the  wireless 
network. 


When  measuring  parameters  related  to  mobile  agents,  we 
used  the  Dartmouth  mobile-agent  system  D’Agents  [6,7]  as 
an  example  of  a  canonical  mobile-agent  platform.  Although 
the  CAST  application  used  a  different  mobile-agent  platform, 
it  was  sufficiently  similar  to  D’Agents  for  the  purposes  of  the 
experiments  here. 


4.  Model  parameters 


4.1.  Measuring  a 


To  explore  some  of  the  performance  space  represented  by  the 
model,  we  need  reasonable  values  for  key  parameters.  In  the 
context  of  the  Fleet  Battle  Experiment  (section  2)  we  have 
B  —  768  kbps  and  K  —  8192  bits.  Using  the  extrapolation 
to  a  realistic  situation,  FBE-Echo  anticipates  F'F  =  0.005, 
r  —  10/s,  and  d  —  600  kbps  (based  on  5  sensors,  each 
generating  100  reports  per  second,  at  150  bytes  per  report). 
This  combination  of  parameters  is  realistic  and  conservative, 
in  that  it  allows  the  broadcast  approach  to  succeed  (because 
d  <  B).8  Let  us  presume  that  an  average  agent  monitors  2 
of  the  5  sensors,  that  is,  F'  —  0.4.  Thus,  if  we  accumu¬ 
late  reports  for  a  t  —  10  s  interval,  the  total  amount  of  data 
D  —  6  mbits,  and  the  agent  must  process  DF'  =  2.4  mbits. 

Unfortunately,  CAST  was  not  instrumented  to  record  any 
specific  information  about  the  computational  cost  or  software 
overhead  a  of  the  CAST  agents.  Thus,  to  measure  the  value 
of  the  other  model  parameters,  we  constructed  a  small  test 
environment  consisting  of  two  Linux  laptops,  a  Linux  work¬ 
station  cluster,  and  a  wireless  network.  One  laptop  served  as 
the  wireless  client  machine.  The  other  laptop  ran  routed 
to  serve  as  a  gateway  between  the  2  Mbps  wireless  network 
and  the  10  mbps  wired  network.  Our  server  cluster  contained 
14  Linux  workstations.  We  treated  the  14  machines  as  a  sin¬ 
gle  logical  server,  because  we  needed  that  many  to  effectively 
measure  /ia,  as  we  describe  below.  The  platform  can  be  envi¬ 
sioned  as  shown  in  figure  4. 9 

8  In  practice,  the  SHF  satellite  network  was  congested  due  to  other  traffic; 
although  we  do  not  model  this  congestion,  it  would  only  lead  to  a  stronger 
case  for  mobile  agents  since  they  require  less  bandwidth. 

9  Client:  Gateway  Solo  2300  laptop;  Intel  Pentium  MMX  200  MHz,  48  MB 

RAM,  running  Linux  2.0.36.  Gateway:  Tecra  500CS  laptop;  Intel  Pen¬ 

tium  120  MHz,  16  MB  RAM,  running  Linux  2.2.6.  Servers:  VA  Linux 
VarStation  28,  Model  2871E;  Pentium  II  at  450  MHz,  512K  ECC  L2 
Cache,  256  MB  RAM,  running  Linux  2.0.36.  Wired  network:  the  gate¬ 
way  was  connected  to  a  10  mbps  Ethernet,  through  a  hub,  a  10  mbps 
switch,  and  a  100  mbps  switch,  to  the  server  cluster.  Wireless  network: 
2  Mbps  Lucent  WaveLAN  “Bronze  Turbo”  802.11b  PC  cards  configured 
at  2  Mbps. 


Because  the  language,  compiler,  and  run-time  system  impose 
overhead,  the  client  runs  at  a  fraction  ac  of  the  full  speed  Sc, 
and  the  server  runs  at  a  fraction  a8  of  the  full  speed  Ss.  Un¬ 
fortunately,  we  do  not  know  and  cannot  directly  measure  .S'. 10 
On  a  single  host  of  speed  S,  though,  we  can  run  a  compiled  C 
program  and  a  comparable  Java  program,  to  obtain  acS  and 
asS,  and  divide  to  obtain  ac/as. 

We  wrote  a  simple  image -processing  application  (an  edge 
detector)  in  C,  and  then  ported  it  to  Java.  We  ran  them  both 
on  one  of  our  servers,  using  a  sample  image;11  averaged  over 
100  runs,  the  Java  program  took  111  ms  and  the  C  program 
took  83  ms.  In  this  measurement,  we  include  only  the  com¬ 
putational  portion  of  the  application,  rather  than  the  time  to 
read  and  write  the  image  files,  since  in  our  modeled  applica¬ 
tion  the  data  will  be  streaming  through  memory,  rather  than 
on  disk.  These  numbers  give  a*  /of  =  0.75,  i.e.,  C  was  25% 
faster  than  Java. 


4.2.  Measuring  /) 


The  raw  bandwidth  of  our  WaveLAN  wireless  network  was 
2  Mbps  (that  is,  2,097,152  bps).  To  obtain  ft  values,  we  mea¬ 
sured  the  transmission  speed  of  sample  applications  transmit¬ 
ting  data  across  that  network,  and  divided  by  2  Mbps. 

To  compute  /lb  for  the  broadcast  case,  we  wrote  a  simple 
pair  of  programs;  one  broadcast  4999  data  blocks  of  50,000 
bytes  each  across  the  wireless  link,  for  the  other  to  receive. 
The  transmission  completed  in  1135  s,  which  implies  that 


Bb  = 


4999  x  50,000  Bytes  x  8  bits/Bytes 
1135  s  ’ 


Bb  1,761,762  bps 

ySb  =  —  =  - - - - —  =  0.840. 

B  2,097,152  bps 


(27) 

(28) 


10  Recall  the  difficulty  of  measuring  the  "peak  performance"  of  an  architec¬ 
ture.  and  all  the  discussions  about  the  value  of  MHz  and  MIPS  as  metrics 
of  performance. 

1 1  The  image  size  was  308,378  bytes,  or  2,467,024  bits,  approximately  the 
value  DF '  =  2.4  mbits  we  mentioned  above. 
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In  other  words,  broadcast  of  these  reasonably  large  chunks  of 
data  is  84%  efficient. 

To  compute  /3a  for  the  agent  case,  we  wrote  a  simple  agent 
program  that  visits  the  server,  and  sends  about  50  KB  of  doc¬ 
uments  every  3  s.  The  agent  completes  after  sending  500  of 
these  50  KB  messages.  The  effective  bandwidth  is  computed 
as  the  total  amount  of  data  transmitted  divided  by  the  time 
required  to  transmit  the  data,  including  the  time  sleeping.  To 
better  reflect  the  modeled  application,  we  actually  sent  out 
several  agents  to  different  hosts  within  our  server  cluster,  and 
increased  the  number  of  agents  and  hosts  until  we  reached  the 
highest  possible  total  bandwidth.  We  found  that  14  agents, 
running  on  separate  hosts  within  the  server  cluster,  reached 
almost  1.5  mbps.  Specifically, 


Ba 

B 


1,484,144  bps 
2,097,152  bps 


0.708. 


(29) 


4.3.  Measuring  C;nit 


When  hosting  agents,  the  server  needs  to  support  all  of  their 
computational  needs.  In  addition  to  the  processing  time  re¬ 
quired  to  filter  the  data,  new  agents  come  and  old  agents  exit. 
In  our  model,  r  agents  come  and  go,  per  second,  on  average. 
We  model  the  computational  overhead  of  each  agent’s  start 
and  exit  as  Cinit-  We  wrote  a  trivial  agent  and  arranged  for 
one  of  our  server  hosts  to  rapidly  submit  agents  to  another 
server  host.  After  5000  submit/exit  pairs  in  204  s,  we  con¬ 
clude  that  the  overhead  C;n ;t  is  about  40  ms  (actually,  it  is  the 
number  of  operations  corresponding  to  40  ms).  It  may  be  less, 
because  our  measurement  was  based  on  wall-clock  time,  not 
CPU  time,  and  this  experiment  did  not  max  out  the  CPU. 


5.  Results 


We  now  use  these  parameters  in  our  equations  to  get  a  sense 
of  how  they  react  under  specific  conditions. 

Unfortunately,  it  is  difficult  to  get  actual  //,  a.  and  S  pa¬ 
rameters,  although  we  did  measure  some  ratios  above.  If  we 
assume,  however,  that  our  edge-detection  algorithm  is  repre¬ 
sentative  of  one  sort  of  filtering  operation,  we  do  know  the 
time  it  took  to  execute  that  operation.  On  our  client  laptop  we 
measured 

— —  =  236  ms.  (30) 

acSc 

That  represents  the  time  needed  to  process  one  308  KByte 
(precisely,  2,467,024  bit)  image;  that  is,  approximately 
DF'  =  2.4  mbits  for  t  =  10  s.  Equation  (19)  tells  us  that 


m 

n 


s?  acSc  - 


10 

0.236 


=  42, 


(31) 


that  is,  about  42  tasks  per  client,  for  an  arbitrary  number 
of  clients  n.  Seen  another  way,  if  the  filter  requires  2.36% 
(236  ms  of  the  10  s  interval)  of  the  client’s  CPU,  the  client 
could  support  42  such  filters.  Of  course,  the  client  machine 
should  reserve  some  power  for  consuming  the  data  after  fil¬ 
tering,  so  it  should  not  run  anywhere  close  to  42  filters. 


Figure  5.  The  number  of  agents  that  can  effectively  be  supported,  as  the 
server  power  grows  relative  to  the  client’s  power.  We  show  four  curves, 
representing  different  possible  computations;  2.36%  represents  our  image- 
processing  sample  application.  In  the  broadcast  case,  each  client  could  sup¬ 
port  100  tasks  (1%),  42  tasks  (2.36%),  10  tasks  (10%),  or  2  tasks  (50%),  for 
an  arbitrary  number  of  clients. 


Similarly,  on  the  server,  if  we  ignore  r,  equation  (6)  tells 
us  that 

m  <  (asSs)  -.  (32) 

The  machines  we  used  as  “servers”  in  our  experiments  were 
not  particularly  speedy.  It  is  more  interesting  to  derive  an 
equation  for  m  in  terms  of  the  relative  power  of  the  server  and 
client,  using  quantities  that  we  already  have  measured: 


m  < 


asSs 

- 1 


acSc  as  Ss 
IX  ac  Sc 


1 

0.236  s 


(0.75)  J  (10  s)  =  31.7  J. 


(33) 


Figure  5  shows  the  total  number  of  agents  (for  all  clients) 
that  could  be  supported  as  the  power  of  the  server  5s  grows 
relative  to  the  power  of  the  clients  Sc,  for  our  236  ms  sample 
task  as  well  as  three  other  possibilities.  The  plot  shows  ra¬ 
tios  Ss/Sc  reaching  up  to  20,  which  is  easily  obtainable  when 
clients  are  portable  computers. 

In  figure  6  we  show  the  constraints  on  m,  in  the  agent  case. 
This  graph  plots  the  two  constraints  from  table  1,  as  d  varies. 
The  actual  constraint  is  the  minimum  of  the  two  curves.  For 
lower  F'F,  the  server’s  computation  is  the  tighter  constraint; 
for  higher  F'F,  the  wireless  network  bandwidth  limits  us 
more.  As  a  basis  for  drawing  these  curves,  we  reconsider 
the  example  inspired  by  FBE-Echo  -  that  is,  d  —  600  kbps, 
1  —  10  s,  and  F'  —  0.4  -  and  measure  the  image-processing 
application  running  on  the  server  (/x/as5s  =  111  ms,  as  de¬ 
scribed  earlier).  Of  course,  in  nearly  any  application  //  will 
vary  with  D  (and  thus,  with  d  and  /);  for  the  purposes  of 
this  illustrative  graph  we  assume  the  computation  is  linear.  In 
other  words,  we  imagine  that  fx  may  behave  as  follows: 


asSs 


1 1 1  ms  x 


D 

10  s  x  600  kbps 


(34) 
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Input  data  rate,  d  (kbps )  Agent  birth/death  rate,  r  per  second 


Figure  6.  The  maximum  number  of  agents  m  we  can  support,  given  the  Figure  7  The  maximum  number  of  agents  m  we  can  supporti  given  the 
constraints  in  table  1.  Here  B  —  768  kbps,  r  =  0,  /3a  =  0.708,  t  =  10  s,  and  constraints  in  table  1,  as  we  vary  r.  Here  we  use  parameters  K  =  1  KByte, 

F  is  proportional  to  D,  as  described  in  the  text.  The  computational  limit  is  B  =  76g  kbps_  d  =  600  kbpSi  ^  =  0  708i  t  =  10  s,  Cinit/(ffsSs)  =  40  ms, 

coincidentally  the  same  as  the  bandwidth  limit  for  F'F  =  0.010.  an(j  p  =  jpj  ms 


In  figure  7  we  look  at  similar  results  when  we  vary  r  (the 
previous  graph  assumed  r  —  0).  In  section  4.3  we  measured 

—  =  40  ms,  (35) 

asSs 

and  in  section  4. 1  we  measured 

-^7  =  m  ms,  (36) 

asSs 

and  for  a  fixed  t  =  10  s,  the  computational  constraint  from 
equation  (6)  is 


Again,  the  actual  constraint  is  the  minimum  of  the  two 
curves.  For  lower  F' F ,  the  server’s  computation  is  the  tighter 
constraint;  for  higher  F'  F,  the  wireless  network  bandwidth 
limits  us  more. 

In  figure  7  the  bandwidth-constraint  lines  are  close  to  hor¬ 
izontal,  since  in  FBE-Echo  the  1  KByte  agents  are  small 
enough  that  the  transmission  of  the  agents  does  not  have  a  sig¬ 
nificant  effect  on  the  wireless  network.  As  shown  in  figure  8, 
on  the  other  hand,  the  behavior  is  dramatically  different  when 
the  agents  are  larger.  For  large  agents  and  high  birth/death 
rates,  the  traffic  induced  by  the  jumping  agents  (rK)  con¬ 
sumes  the  available  bandwidth  5a,  leaving  nothing  for  agents 
to  transmit  their  data.  Clearly,  such  a  system  can  support  few 
agents  when  the  agent  size  is  large  or  when  the  birth/death 
rate  is  high.  This  result  emphasizes  the  need  to  include  some 
kind  of  code  caching  in  any  mobile-code  system,  so  that  the 
same  agent  code  is  not  transmitted  repeatedly  across  the  wire¬ 
less  link. 

Another  useful  way  to  look  at  the  results  is  to  graph  the 
bandwidth  required  by  either  the  agent  approach  or  the  broad¬ 
cast  approach,  given  certain  parameters.  In  figure  9  we  vary 
the  filtering  ratio,  since  it  clearly  has  a  large  impact  on  the 


Agent  birth/death  rate,  r  per  second 


Figure  8.  For  comparison  with  figure  7,  we  fix  F' F  =  0.005  as  in  FBE-Echo, 
and  instead  display  the  bandwidth  limit  with  K  =  1,  10,  or  50  KBytes.  Other 
parameters  are  the  same  as  in  the  preceding  figure. 


bandwidth  required  by  the  agent  approach.  For  low  filter¬ 
ing  ratios,  the  agent  approach  needs  less  bandwidth  than  the 
broadcast  approach.  If  d  >  B  (not  shown),  of  course  the 
broadcast  approach  cannot  work  at  all,  and  the  agent  approach 
is  the  only  solution. 

In  figure  1 0  we  show  the  relationship  between  the  number 
of  agents  and  the  necessary  filtering  ratio.  Another  view  on 
the  earlier  charts,  this  clearly  shows  that,  to  support  a  large 
number  of  agents,  those  agents  must  be  aggressively  filtering 
the  input  stream. 

In  all,  it  is  clear  that  there  is  a  wide  range  of  situations 
in  which  mobile  agents  are  more  efficient  than  the  broadcast 
approach.  Unless  the  number  of  clients  is  very  large,  the  fil¬ 
tering  ratio  of  each  task  is  high,  or  the  size  or  computational 
demands  of  each  task  is  high,  the  mobile-agent  approach  has 
promise. 
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Filtering  Ratio  F’F 

Figure  9.  The  bandwidth  requirements  for  agent  and  broadcast  approaches. 
Here  d  =  600  kbps,  B  =  768  kbps,  r  =  10/s,  K  =  1  KByte,  /3a  =  0.708, 
and  fa  =  0.840.  Note  that  the  bandwidth  required  by  the  broadcast  approach 
is  d/fib,  and  appears  above  d. 


Figure  10.  The  relationship  between  the  filtering  ratio  and  the  number  of 
agents  in  the  server.  Other  parameters  are  as  before:  B  =  768  kbps, 
d  =  600  kbps,  K  =  1  KByte,  r  =  10/s. 

6.  Related  work 

Performance  modeling  of  computer  networks  and  distributed 
applications  is  an  old  field,  and  our  approach  and  resulting 
equations  are  similar  to  many  previous  analyses  of  distrib¬ 
uted  systems  [10].  In  addition,  there  has  been  some  similar 
modeling  work  specifically  for  mobile-agent  systems. 

Strasser  and  Schwehm  [16]  develop  a  general  model 
for  comparing  the  performance  of  Remote  Procedure  Calls 
(RPC)  with  the  performance  of  migrating  agents.  Using  their 
model,  which  is  best-suited  for  information-retrieval  appli¬ 
cations,  they  derive  equations  for  the  total  number  of  bytes 
transferred  across  the  network,  as  well  as  the  total  completion 
time  of  the  task.  The  equations  include  such  parameters  as 
the  expected  result  size  and  the  “selectivity”  of  the  agent  (i.e., 
how  much  irrelevant  information  the  agent  filters  out  at  the 
data  site,  rather  than  carrying  with  it  for  future  examination). 
Their  byte  equations  are  similar  to  our  bandwidth  equations, 
although  their  time  equations  are  not  directly  applicable  to  our 


scenario,  since  we  are  interested  only  in  whether  the  server 
can  keep  up  with  the  incoming  data  streams,  not  with  the  to¬ 
tal  completion  time, 

Ktipper  and  Park  [11]  examine  a  signaling  application  in¬ 
side  a  telecommunications  network,  and  compare  a  mobile- 
agent  approach  with  a  stationary-agent  (or  client-server)  ap¬ 
proach.  Starting  with  a  queuing  model  of  a  hierarchical  sig¬ 
naling  network,  they  produce  equations  that  specify  the  ex¬ 
pected  load  on  each  network  node  in  both  the  mobile  and  sta¬ 
tionary  cases.  These  equations  are  similar  to  our  server-load 
equations  (from  which  we  derive  the  constraint  on  how  many 
agents  the  server  machine  can  handle  simultaneously). 

Picco,  Fuggetta  and  Vigna  [4,12]  identify  three  main  de¬ 
sign  paradigms  that  exploit  code  mobility:  remote  evaluation, 
code  on  demand,  and  mobile  agents.  Within  the  context  of 
a  network-management  application,  i.e.,  the  polling  of  man¬ 
agement  information  from  a  pool  of  network  devices,  they  an¬ 
alyze  these  three  paradigms  and  the  traditional  client-server 
paradigm.  They  develop  analytical  models  to  compare  the 
amount  of  traffic  around  the  network-management  server,  as 
well  as  the  total  traffic  on  the  managed  network.  These  mod¬ 
els  are  similar  to  our  bandwidth  models. 

More  recently,  Puliafito  et  al.  [13]  used  Petri  nets  to  com¬ 
pare  the  mobile-agent,  remote-evaluation  and  client-server 
paradigms.  The  key  parameters  to  the  models  are  transition 
probabilities  that  specify  (1)  whether  a  traditional  client  or 
agent  will  need  to  redo  an  operation,  and  (2)  whether  a  client 
or  agent  will  need  to  perform  another  operation  to  continue 
with  the  overall  task.  Using  the  models,  they  compare  the 
mean  time  to  task  completion  for  the  three  paradigms.  Like 
the  the  work  of  Strasser  and  Schwehm  [16],  these  Petri-net 
models  are  well  suited  for  information-retrieval  applications, 
are  more  general  than  the  models  in  the  other  papers,  and  are 
not  directly  applicable  to  our  scenario,  which  involves  con¬ 
tinuous  filtering  of  an  incoming  data  stream,  rather  than  a 
multi-step  retrieval  task.  Petri  nets,  however,  could  be  a  useful 
analysis  technique  for  our  scenario. 

In  addition  to  the  mathematical  analyses  above,  there  has 
been  a  range  of  simulation  and  experimental  work  for  mobile- 
agent  systems.  Recent  simulation  work  includes  [15],  which 
considers  the  use  of  mobile  agents  for  search  operations  on  re¬ 
mote  file  systems  (such  as  the  standard  substring  search  of  the 
Unix  grep  command),  and  [  1],  which  examines  the  use  of  mo¬ 
bile  agents  for  message  delivery  in  ad  hoc  wireless  networks. 
Recent  experimental  work  includes  [  14],  which  compares  dif¬ 
ferent  strategies  for  accessing  a  Web  database,  and  [5],  which 
compares  RPC  and  mobile-agent  approaches  for  accessing  a 
document  database.  Although  we  have  not  done  simulation 
or  experimental  validation  of  our  model  yet,  such  validation 
is  an  essential  part  of  future  work. 

In  our  broadcast  scenario  all  of  the  data  are  broadcast.  In 
our  agent  scenario  each  agent  sends  its  own  copy  of  the  fil¬ 
tered  data  to  its  client,  regardless  of  whether  other  clients  may 
also  want  the  data.  We  may  be  able  to  use  techniques  from  the 
domain  of  “broadcast  publishing”  to  obtain  a  more  efficient 
compromise  approach  [9]. 
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7.  Summary  and  future  work 

The  FBE-Echo  experiment  is  a  good  example  of  an  applica¬ 
tion  in  which  only  a  small  portion  of  the  available  information 
is  relevant  to  the  task  at  hand.  Although  the  FBE-Echo  ex¬ 
perimental  results  suggested  that  mobile  agents  were  achiev¬ 
ing  significant  bandwidth  savings,  the  aggressive  FBE  testing 
schedule  did  not  allow  a  direct  comparison  with  a  traditional 
client/server  implementation.  For  this  reason,  we  developed 
the  model  described  in  this  paper,  which  confirms  that  mo¬ 
bile  agents  will  often  have  a  significant  performance  benefit 
in  filtering  applications.  With  small  filtering  ratios  (F'F)  or  a 
small  numbers  of  agents,  a  mobile-agent  approach  can  get  by 
with  less  bandwidth  or  slower  (i.e.,  cheaper  or  lighter)  clients. 
At  the  same  time,  our  analysis  reinforces  the  importance  of 
the  engineering  challenge  of  keeping  as  and  large,  that  is, 
reducing  the  overhead  of  mobile-agent  computation  and  com¬ 
munication. 

To  further  develop  this  performance  analysis  and  to  use  it 
in  a  wider  range  of  applications,  we  need  to  better  understand 
several  issues:  How  variable  is  the  input  data  stream  in  terms 
of  its  flow  rate?  In  other  words,  how  much  buffering  would 
be  necessary  in  the  server  and  the  clients?  How  many  differ¬ 
ent  agent/task  types  are  there  in  typical  applications,  and  how 
widely  do  these  types  vary?  How  much  CPU  time  is  needed 
to  support  the  network  protocols?  Are  average  or  expected 
numbers  acceptable,  or  do  we  need  worst-case  analysis? 

Furthermore,  we  need  to  address  a  few  limitations:  (1)  the 
broadcast  case  assumes  that  nobody  misses  any  transmis¬ 
sions,  or  that  they  do  not  care  if  they  miss  it,  so  there  are 
no  retransmissions;  (2)  both  cases  ignore  the  client  process¬ 
ing  consumed  by  the  end  application;  and  (3)  we  consider 
only  one  application  scenario.  While  the  application  scenario 
is  widely  representative,  there  are  certainly  other  application 
types  worth  analyzing.  In  particular,  we  would  like  to  con¬ 
sider  scenarios  in  which  the  mobile  agents  move  up  and  down 
a  hierarchy  of  gateway  machines.  We  are  also  interested  in  the 
use  of  mobile  agents  as  a  dynamically  distributed,  and  redis¬ 
tributed,  cooperative  cache  to  support  mobile  computers  in  a 
wireless  network. 
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